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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document gives the stage 2 description of Lawful Interception within a PLMN for circuit switched systems 
and GPRS. It does not address the interface between the PLMN and the LEA lawful intercepted product and related 
information collection functions. This is outside the scope of the GSM standard. 

The structure of the present document is as follows: 

clause 4 covers the architecture of the interception system; 

clause 5 describes how interception is activated, deactivated and interrogated within the interception system; 

clause 6 describes how the system is provisioned, defines events at which interception takes place and what kind 
of information is generated at each event; 

clause 7 provides brief descriptions of various intercept cases; 

clause 8 reviews security requirements for access to the interception system; 

annex A provides information flows to illustrate when intercepted traffic and related data is generated; 

annex B describes an interception system for GPRS. The annex is subdivided into 5 sections that are identical in 
structure to clauses 4 through 8, but applicable to a GPRS clause rather than a GSM circuit switched system. 
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[4] GSM 03.60: "Digital cellular telecommunications system (Phase 2+); GPRS Service description 

stage 2". 
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Definitions and abbreviations 



3.1 



Definitions 



Definitions can be found in 3GPP TS 42.033 in the stage 1 description of Lawful interception and in GSM 03.60, the 
stage 2 service description for GPRS. 



3.2 



Abbreviations 



In addition to those below abbreviations used in the present document are listed in GSM 01.04. 

ADMF Administration Function 

DF2 Delivery Function 2 

DF2P Delivery Function 2 for GPRS 

DF3 Delivery Function 3 

DF3P Delivery Function 3 for GPRS 

GCI Global Cell Identity 

GSN GPRS Support Node (i.e.SGSN or GGSN) 

lA Interception Area 

IP Intercept Product 

IRI Intercept Related Information 

LEA Law Enforcement Agency 

SCI Subscriber Controlled Input 



4 Functional architecture 

The following picture contains the reference configuration for the lawful interception. The various entities and 
interfaces are described in more detail in the succeeding subclauses. 

There is one Administration Function (ADMF) in the network. Together with the delivery functions it is used to hide 
from the MSCA'^LR and GMSC that there might be multiple activations by different Law Enforcement Agencies 
(LEAs) on the same target. 
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Figure 1: Reference configuration 

The reference configuration is only a logical representation of the entities involved in lawful interception and does not 
mandate separate physical entities. This allows for higher levels of integration. 
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5 Activation, deactivation and interrogation 

The following picture shows the extract from the reference configuration which is relevant for activation, deactivation 
and interrogation of the lawful interception. 
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Figure 2: Functional model for Lawful Interception activation, deactivation and interrogation 

In addition to the typical GSM functional entities, a new functional entity is introduced - the ADMF - the Lawful 
Interception administration function. The ADMF: 

interfaces with all the LEAs that may require interception in the PLMN; 

keeps the intercept activities of individual LEAs separate; 

- interfaces to the PLMN. 

NOTE: The Xl_l, Xl_2 and Xl_3-interfaces together are functionally equivalent to the Xl-interface represented 
in 3GPP TS 4L033. 

Every physical MSC/VLR and GMSC is linked by an own Xl_l -interface to the ADMF. Consequently, every single 
MSC/VLR and GMSC performs interception (activation, deactivation, interrogation as well as invocation) 
independently from other MSC/VLRs and GMSCs. The X0_1 -interface represents the interface between the requester 
of the lawful interception and the Lawful administration function; it is included for completeness, but is beyond the 
scope of standardization. 

In case of location dependent interception the following network/national options exist: 

target location versus Interception Areas (lAs) check in the MSC/VLR and Delivery Functions (DFs); 

target location versus lAs check in the DFs (physical collocation of the DFs to the MSC/VLR, GMSC is 
required). 

NOTE: The lA is previously defined by a set of cells. From the location of the target this set of cells permits to 
find the relevant I A. 
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5.1 



Activation 



The following pictures show the information flow for the activation of the Lawful interception. 

5.1.1 XI _1 -interface 

The message sent from the ADMF to the MSC/VLR and GMSC respectively (Xl_l -interface) contains the; 

- identity of the target (MSISDN, IMSI or IMEI) (see note 4); 

information whether the intercept product shall be provided (see note 1); 

information whether the intercept related information shall be provided (see note 1); 

address of Delivery Function 2 (DF2) for the intercept related information (see note 2); 

address of Delivery Function 3 (DF3) for the circuit switched intercept product (see note 3); 

lA in case of location dependent interception. 

NOTE 1 : As an option, the filtering whether intercept product and/or intercept related information has to be 

provided can be part of the delivery functions. If the option is used, the corresponding information can be 
omitted on the Xl_l-interface, while "information not present" means "intercept product and related 
information has to be provided" for the MSC. Furthermore the delivery function which is not requested 
has to be "pseudo-activated", in order to prevent error cases at invocation. 

NOTE 2: As an option, only a single DF2 is used by and known to every MSC in the network. In this case the 
address of DF2 can be omitted. 

NOTE 3: As an option, only a single DF3 is used by and known to every MSC in the network. In this case the 
address of DF3 can be omitted. 

NOTE 4: Interception of IMEI is not applicable at the GMSC. 

If after activation subsequently Intercept Product (IP) or Intercept Related Information (IRI) has to be activated (or 
deactivated) an "activation change request" with the same identity of the target is to be sent. 
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Figure 3: Information flow on X1_1 -interface for Lawful Interception activation 

Interception of a target can be activated on request from different LEAs and each LEA may request interception via a 
different identity. In this case, each identity of the target on which to intercept will need to be sent via separate 
activation message from ADMF to MSC/VLR and GMSC on the Xl_l -interface. Each activation can be for IP only, 
IRI only, or both IP and IRI. 
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When several LEAs request activation on the same identity then the ADMF determines that there are existing 
activations on the identity. In this case, the ADMF will not send an additional activation message to the MSCA'LR and 
GMSC except when the activation needs to change from IP only or IRI only to IP and IRI. In that case an activation 
change message will be sent to the MSC/VLR and GMSC. 

5.1.2 X1_2-interface (IRI) 

For the delivery of IRI the message sent from the ADMF to the Delivery Function contains: 

the identity of the target; 

the address for delivery of IRI (= LEA address); 

which subset of information shall be delivered; 

a DF2 activation identity, which uniquely identifies the activation for DF2 and is used for further interrogation or 
deactivation, respectively; 

the lA in case of location dependent interception; 

the warrant reference number if required by national option. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single activation of delivery is 
necessary for each combination of LEA and identity. 
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Figure 4: Information flow on X1_2-interface for Lawful Interception activation 

5.1.3 X1_3-interface(IP) 

For the delivery of circuit switched intercept product the message sent from the ADMF to the Delivery Function 
contains: 

the identity of the target; 

the address of delivery for IP (= LEA address); 

a DF3 activation identity, which uniquely identifies the activation for delivery function 3 and is used for further 
interrogation or deactivation, respectively; 

the lA in case of location dependent interception; 

the warrant reference number if required by national option. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single activation of delivery is 
necessary for each combination of LEA and identity. 



ETSI 



3GPP TS 43.033 version 9.0.0 Release 9 



12 



ETSI TS 143 033 V9.0.0 (2010-02) 



ADMF 



DF3 



request for lawful 
interception activation 



response for lawful 
interception activation 



lawful interception 
activation 



lawful interception 
activation ack 



... activation on X1 1 
andX1 2... 



Figure 5: Information flow on X1_3-interface for Lawful Interception activation 

5.2 Deactivation 

The following picture shows the information flow for the deactivation of the Lawful interception. 

5.2.1 X1_1 -interface 

The messages sent from the ADMF to the MSCA'LR and GMSC for deactivation contains: 
the identity of the target; 
the possible relevant lAs in case of location dependent interception. 
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Figure 6: Information flow on X1_1 -interface for Lawful Interception deactivation 

If interception of a target has been activated via different identities then a separate deactivation message will need to be 
sent from the ADMF to the MSC/VLR and the GMSC for each identity. 

When several LEAs requested activation on the same identity and subsequently request deactivation then the ADMF 
determines that there are remaining activations on the identity. In this case, the ADMF will not send a deactivation 
message to the MSC/VLR and the GMSC except when the activation needs to change from IP and IRI to IP only or IRI 
only. In that case an activation change message will be sent to the MSC/VLR and the GMSC. 
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5.2.2 X1_2-interface (IRI) 



The ADMF sent for the deactivation to the DeHvery Function 2 of the Intercept Related Information: 

a DF2 activation id, which uniquely identifies the activation to be deactivated for DF2. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single deactivation is necessary for 
each combination of LEA and identity. 
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Figure 7: Information flow on X1_2-interface for Lawful Interception deactivation 

5.2.3 X1_3-interface(IP) 

For the deactivating the delivery of the IP the message from the ADMF to the Delivery Function contains: 

a DF3 activation id, which uniquely identifies the activation to be deactivated for DF3. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single deactivation is necessary for 
each combination of LEA and identity. 
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Figure 8: Information flow on X1_3-interface for Lawful Interception deactivation 
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5.3 Interrogation 

The purpose of interrogation is consistency checking for the interception function. It can be use e.g. for audit 
functionality, but this is beyond the scope of the present document. 

Interrogation of all activations for a given LEA is an ADMF filter function. 

5.3.1 Interrogation of the MSC/VLR and the GMSC 

The following picture shows the information flow for the interrogation of the Lawful interception. It must be possible to 
interrogate 

a specific activation at this MSC/VLR or GMSC for a given target identity; 

- all activations at this MSC/VLR or GMSC. 

As result of the interrogation the activation status and data are returned. 
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Figure 9: Interrogation of the Lawful Interception (IVISC/VLR, GMSC) 

5.3.2 Interrogation of Delivery Functions 

The following picture shows the information flow for the interrogation of the Lawful interception. It must be possible to 
interrogate: 

a specific activation at a Delivery Function for a given activation id; 

all activations at a Delivery Function for a given target identity; 

all activations at a Delivery Function. 

As result of the interrogation the activation status and data are returned. 
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Figure 10: Interrogation of the Lawful Interception (Delivery Functions) 



Invocation of Lawful Interception 



The following picture shows the extract from the reference configuration which is relevant for the invocation of the 
lawful interception. 
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Figure 11: Functional model for Lawful Interception invocation 

The X0_2 and X0_3-interfaces represent the interfaces between the LEA and two delivery functions. Both interfaces are 
subject to national requirements. They are included for completeness, but are beyond the scope of standardization. The 
delivery functions are used: 

to convert the information on the X2-interface to the corresponding information on the X0_2-interface; 

to distribute the intercept related information to the relevant LEA(s) (based on lAs, if defined); 

to distribute the intercept product to the relevant LEA(s) (based on lAs, if defined). 

In case a call is selected based on several identities (MSISDN, IMSI, IMEI) of the same target, the MSC/VLR or 
GMSC will deliver IP and IRI only once to the DF2 and DF3. DF2 and DF3 will then distribute the information to the 
relevant LEA that requested interception on a particular target identity. 

For the delivery of the IP and IRI the MSCA'^LR or GMSC provides correlation number and target identity to the DF2 
and DF3 which is used there in order to select the different LEAs where the product shall be delivered to. 

NOTE: If interception has been activated for both parties of the call both IP and IRI will be delivered for each 
party as separate intercept activity. 

The location dependency check occurs at the establishment of each call. Subsequent dependency checks for 
simultaneous calls are not required, but can be a national option. 

If a target is marked using an lA in the MSCA'LR, the MSC/VLR shall perform a location dependency check at call 
set-up. Only if the target's location matches the lA the call is intercepted. 
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If a target is marked using an lA in the DF2, the DF2 shall perform a location dependency check at reception of the first 
IRI for the call. Only if the target's location matches the lA for certain LEAs the IRI is relayed to these LEAs. All 
subsequent IRIs for the call are sent to the same LEAs. 

If a target is marked using an lA in the DF3, the DF3 shall perform a location dependency check at reception of the IP. 
Only if the target's location matches the I A for certain LEAs the IP is relayed to these LEAs. 

Gateway intercept is not possible when optimal routing is employed. 

6.1 Provision of Intercept Product - Circuit Switched 

Depending on the existing possibilities within the MSC/VLR or GMSC the access method for the delivering of call 
content can be bridged/ T-connection (see figure 12) or looped access (see figure 13). 
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Figure 12: Bridged Access 
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6.1 .2 Two stubline configuration (circuit switclned data or speecin) to LEA 

Figure 16 shows the configuration for a circuit switched data call. The signals of both parties of the configuration to be 
intercepted are delivered separately to the requesting function. Again the requesting function itself has no impact on the 
connection between the subscribers. Optionally this configuration can be used for speech, too. 

If in the MSC/VLR or GMSC it isn't known if a call is a data or speech call, it will be assumed that it is a data call. 

The two stublines towards the requesting function are established in parallel to the call set up. For both stublines the 
address is used which has been provided during activation. 

For multi-monitoring the DF3 must be able combine the two stublines to one, if one of the different LEAs wants this. 

NOTE: For data calls it is necessary to provide means for fast call establishment towards the LEA so that it 
doesn't miss the beginning of the data transmission. 
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Figure 16: Two stubline configuration to the LEA for the interception of 
a circuit switched data or speech call 

6.1.3 X3-interface 

The following information needs to be transferred from the MSC/VLR or the GMSC to the DF3 in order to allow the 
DF3 to perform its functionality: 

- the identity of the target (MSISDN, IMSl or IMEI); note 1 

the target location (if available) or the lAs in case of location dependent interception, note 1 

- correlation number (IRI <-> CC); 

- signal indicator (direction indication - Signal from target or signal to target); note 2 
NOTE 1 : For DF3 internal use only. 

NOTE 2: e.g. integer, CC from target = 1, CC from other party = 2. 
Additional information may be provided if required by national laws. 
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6.2 Provision of Intercept Product - Short IVIessage Service 

Figure 17 shows an SMS transfer from the MSC to the LEA. Quasi-parallel to the delivery from / to the mobile 
subscriber a message, which contains the contents of the SMS, is generated and sent via the Delivery Function 2 to the 
LEA in the same way as the Intercept Related Information. 

The IRI will be delivered to the LEA: 

- for a SMS-MO, when the SMS-Centre receives the SMS; 

- for a SMS-MT, when the MS receives the SMS. 
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Figure 17: Provision of Intercept Product - Short Message Service 



6.3 Provision of Intercept Related Information 

Intercept Related Information (Events) are necessary at the Begin and End of the call, for all supplementary services 
during a call and for information which are not call associated. There are call related events and non call related events 

Figure 18 shows the transfer of intercept related information to the DF2. If an event for / from a mobile subscriber 
occurs, the MSCA^LR or GMSC sends the relevant data to the DF2. 
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Figure 18: Provision of Intercept Related Information 
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6.3.1 X2-interface 

The following information needs to be transferred from the MSC/VLR or the GMSC to the DF2 in order to allow a DF2 
to perform its functionality: 

- identity of the target (MSISDN, IMSI or IMEI); 

the target location (if available) or the lAs in case of location dependent interception; 

- events and associated parameters as defined in subclauses 6.3.3 and 6.3.4 may be provided. 

6.3.2 Structure of the events 

There are eight different events in which the information is sent to the DF2 if this is required. There are call related and 
non call related events. Details are described in following subclause. The events for interception are configurable (if the 
are sent to DF2) in the MSC/VLR or GMSC and can be suppressed in the DF2. 

It is a implementation option if the redundant information will be sent for each further event. 

The following events are applicable to the MSC/VLR: 

Call related events: 

Call establishment; 

Answer; 

Supplementary service; 

Handover; 

- Release. 

Non call related events: 

- SMS; 

Location update; 

Subscriber controlled input. 

The following events are applicable to the GMSC: 
Call related events: 

Call establishment; 

Answer; 

Supplementary service; 

- Release. 
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A set of information is used to generate the events. The events transmit the information from MSC/VLR or GMSC to 
DF2. This set of information can be extended in MSC/VLR or GMSC, if this is necessary in a specific country. DF2 can 
extend this information if this is necessary in a specific country e.g. a unique number for each surveillance warrant. 



observed MSISDN 

Target Identifier with the MSISDN of the target subscriber (monitored subscriber). 



observed IMSI 

Target Identifier with the IMSI of the target subscriber (monitored subscriber). 



observed IMEI 

Target Identifier with the IMEI of the target subscriber (monitored subscriber), 
it must be checked for each call over the radio interface 



event type 

Description which type of event is delivered: Establishment, Answer, Supplementary service, 
Handover, Release, SMS, Location update. Subscriber controlled input 



event date 

Date of the event generation in the MSC/VLR or GMSC 



event time 

Time of the event generation in the MSC/VLR or GMSC 



dialled number 

Dialled phone number before digit modification, IN-modification etc. 



connected number 

number of the answering party 



other party address 

Directory number of the other party for MOC 
Calling party for MTC 



SMS -Centre address 

number of the involved SMS-Centre 



call direction 

Information if the monitored subscriber is calling or called e.g. MOC/MTC or originating/ terminating 
in or/out 



correlation number 

Unique number for each call sent to the DP, to help the LEA, to have a correlation between each 
call and the IRI 



cell id 

Cell number of the target; for the location information 



location area code 

Location-area-code of the target defines the Location Area in a PLMN 



basic service 

Information about Tele service or bearer service. 



supplementary service 

Supplementary services used by the target e.g. CF, CW, ECT 



forwarded to number 

Forwarded to number at CF 



call release reason 

Call release reason of the target call 



SMS 

The SMS content with header which is sent with the SMS -service 



SCI 

Non call related Subscriber Controlled Input (SCI) which the MSC/VLR receives from the ME 
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6.3.3 Call Related events 



6.3.3.1 



Call establishment 



For call establishment a call establishment-event is generated. At the begin of a call when the MSC/VLR or GMSC 
wants to reach the subscriber this event is generated. This information will be delivered to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



dialled number 



other party address 



call direction 



correlation number 



cell id 



location area code 



basic service 



supplementary service 



6.3.3.2 Answer 

If the called party answers, a answer- event is generated. This information will be delivered to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



dialled number 



other party address 



connected party 



call direction 



correlation number 



cell id 



location area code 



basic service 



supplementary service 
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6.3.3.3 



Supplementary Services 



For supplementary services event are generated with the information which supplementary service is used e.g. Call 
Forwarding (CF), Call Waiting (CW), Explicit Call Transfer (ECT), Multi Party (MPTY), Call Hold and information 
correlated to the service like the forwarded to number. This information will be delivered to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



dialled number 



other party address 



call direction 



correlation number 



cell id 



location area code 



basic service 



supplementary service 



forwarded to number 



6.3.3.4 



Handover 



For each handover a handover-event with the information about the new location (cell-id) is generated. This information 
will be delivered to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



correlation number 



cell id 



location area code 



6.3.3.5 



Release 



For release of the observed call a release-event is generated, this is for the common (end) release of call and also for all 
failed call attempts, with the information about the reason for failed call attempts. This information will be delivered to 
the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



dialled number 



other party address 



call direction 



correlation number 



cell id 



location area code 



basic service 



call release reason 
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6.3.4 Non Call Related events 



6.3.4.1 



SMS 



For MO-SMS the event is generated in the MSCA^LR, when the SMS-Centre successfully receives the SMS; for MT- 
SMS the event is generated in the MSCA'^LR when the target receives the message. This information will be delivered 
to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



SMS-Centre address 



call direction 



cell id 



location area code 



SMS 



6.3.4.2 



Location update 



For location updates a Location update-event is generated, with the new location (location area) information. This 
information will be delivered to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



cell id 



location area code 



6.3.4.3 



Subscriber Controlled Input (SCI) 



For subscriber controlled inputs (e.g. this are activations, deactivations and changes of services) a SCI-event is 
generated with information about the SCI. This information will be delivered to the DF2 if available: 



observed MSISDN 



observed IMSI 



observed IMEI 



event type 



event date 



event time 



cell id 



location area code 
SCI 
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6.4 Intercept cases for supplementary services 
6.4.1 Interception of Multiparty call 
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Figure 19: Option 1 : Interception of lUlultiparty for IP 
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Figure 20: Option 2: Interception of IVIultiparty for IP 



Intercept Product only for Multiparty 



One correlation number for each leg of a call. Call Content is delivered like it is in figure 19 or in figure 20 if 
subscriber A is monitored. 

If one of B, C or D is monitored, the surveillance of intercept product works like a ordinary telephony call. 
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6.4.1.2 



Intercept Related Information for Multiparty 



In the event is the information about B, C and D if subscriber A is monitored. If one of B, C or D is monitored in the 
events is only the information about A but not the other parties of the conference. 

6.4.2 Interception for Call Forwarding / Call Deflection 



5^a 




Figure 21 : Interception for Call Forwarding / Deflection 

For delivery of the Intercept Product it doesn't matter which of the three is monitored. 

For Intercept Related Information it depends who is monitored: 

If subscriber A is monitored the number of A and B are mandatory in the event information and the number of C 
if available. 

If subscriber B is monitored the number of B and C are mandatory in the event information and the number of A 
if available. 

If subscriber C is monitored the number of C is mandatory in the event information and the number of A if 
available. 

When optimal routing is employed, interception of call forwarding by party B may be unavailable. 

6.4.3 Interception on Call Hold / Call Waiting 

For interception on call hold it depends which method is used, if it is like in figure 19 no interception on call hold is 
possible, with the method like in figure 20 it is also possible to hear what the subscriber on hold is talking. 



6.4.4 Interception after ECT 



For interception on Explicit Call Transfer (ECT) it depends which method is used, if it is like in figure 19 no 
interception on call hold is possible, with the method like in figure 20 it is also possible to hear what the subscriber on 
hold is talking. The explicit transfer is handled similar to a forwarded call. 
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7 Security 

7.1 Security 

The security requirements are valid for the whole Lawful Interception system, i.e. rules and procedures shall be used for 
all involved entities, ADMF, GMSC, MSC/VLR and DF. 

7.1.1 Administration security 

The administration of the lawful interception function, i.e. Activation, Deactivation and Interrogation of Lawful 
Interception, in the GMSC, MSCA'^LR and the DFs must be done secure as described below: 

It shall be possible to configure the authorised user access to Activation, Deactivation and Interrogation of 
Lawful Interception separately for every physical or logical port at the GMSC, MSC/VLR and DF. This 
configuration possibility shall be password protected. 

Normally only the ADMF is allowed to have access to the lawful interception functionality in the GMSC, 
MSC/VLR and DF. 

The communication link between ADMF, GMSC, MSC/VLR, DF2 and DF3 shall be secure and shall support 
security mechanisms, e.g.: 

- authentication; 

- Closed Used Group (CUG); 

Connected Line Presentation (COLP); 

encryption. 

No network entities or remote access shall be capable to manipulate or to eavesdrop lawful interception data in 
the GMSC, MSC/VLR or the DF. 

7.1.2 IRI security 

7.1.2.1 Normal operation 

The transmission of the IRI shall be done in a secure manner. 

When DF2 is a physically separate from the MSC, the X2-interface shall support security mechanisms, e.g.: 

- authentication; 

- CUG; 

- COLP; 

- encryption. 

7.1 .2.2 Communication failure 

Depending on the national law in case of communication failure IRI may be buffered in the GMSC and MSC/VLR. 
After successful transmission of IRI the whole buffer must be deleted. It shall be possible to delete the content buffer 
via command or a timer, in an unrestoreable fashion. 
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7.1.3 IP security 

The transmission of the IP shall be done in a secure manner. 

When DF3 is physically separate from the MSC, the X3-interface shall support security mechanisms, e.g.: 
authentication; 

- CUG; 

- COLP; 

- encryption. 

In case of transmission failure no buffering will be done. 

7.1 .4 Security aspects of Lawful Interception charging 

Charging information shall be available at the DFs and the ADMF. Charging information for Lawful Interception shall 
be separated from "regular" GSM billing data. 

Charging data transmission to the Lawful Interception billing system shall be done in a secure manner. 

In case of transmission failure data shall be buffered/stored in a secure way. After successful transmission data shall be 
deleted in an unrestorable fashion. 

7.1 .5 Other security issues 

7.1.5.1 Log files 

Log files shall be generated by the ADMF, DF2, DF3 and the MSCA^LR. All log files are retrievable by the ADMF, 
and are maintained by the ADMF. 

7.1 .5.2 Data consistency 

The administration function in the PLMN shall be capable to perform a periodic consistency check to ensure whether 
the target list of MSISDN, IMSI or IMEI is the same in all involved MSCs in the PLMN and the DFs. The reference 
data base is the ADMF data base. 
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Annex A (normative): 

Information flows for Lawful Interception invocation 

The following figures show the information flows for the invocation of Lawful Interception for various types of calls. 
The figures show some of the basic signalling messages of the target calls and the events on the X2 and X3-interfaces. 
The ISUP messages to and from the network are shown for informational purposes only; some of them may not be sent 
or may be combined in certain networks. 



A.1 Mobile originated circuit switched calls 

Figure A.l shows the interception of a basic mobile originated circuit switched speech or data call where the originating 
mobile (A) is the target for interception. B is not necessarily also a mobile subscriber and resides on a different 
exchange. 
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Figure A.1 : Interception of mobile originated circuit switched calls 

In figure A. 1 the result (answer) of the set-up of the stublines is not shown. This assumes no special action is taken in 
case of failure. 
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A.2 Mobile terminated circuit switched calls 

Figure A.2 shows the interception of a basic mobile terminated circuit switched speech or data call where the 
terminating mobile (B) is the target for interception. A is not necessarily also a mobile subscriber and resides on a 
different exchange. 
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Figure A.2: Interception of mobile terminated circuit switched calls 
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A.3 Call hold / call waiting 



Figures A.3 and A.4 show the interception of calls involving call hold / call waiting. Figure A.3 covers the case where 
one pair of stublines is used per target, figure A.4 covers the case where a pair of stublines is used for each target call. 
The mobile that receives the waiting call (A) is the target for interception. 
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Figure A.3: Interception of call hold / call waiting - stublines per target 
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Figure A.4: Interception of call hold / call waiting - stublines per target call 



A.4 Multiparty calls 



Figures A. 5 and A.6 show the interception of multiparty calls. Figure A. 5 covers the case where one pair of stublines is 
used per target, figure A.6 covers the case where a pair of stublines is used for each target call. The mobile setting up 
the multiparty call (A) is the target for interception. 



ETSI 



3GPP TS 43.033 version 9.0.0 Release 9 



32 



ETSI TS 143 033 V9.0.0 (2010-02) 



DF2 



DF3 



stublines cor tain IP of AB 



stublines cor tain IP of AC 



stublines con. ain IP of ABC 



stublines cor tain IP of AC 



stublines cor tain IP of AB 



MS A MSC/VLR 

SETUP(AB) 



Sjippl. Service(AB, CHOLp) 
SETUP(AC) 



S ippl. Service(AB, BMPT 



Siippl. Service(AC, BMPT 



... setup and interception of AB call 
as in figure A1 ... 



Answer(AB) 



HOLD(AB) 



HOLD ACK(AB) 



... setup and interc jption of AC call as 
without setup of stublines ... 



Answer(AC) 



BuildMPTY(AB) 



BuildMPTY ACK(AB) 



SplitMPTY(AC) 



SplitMPTY ACK(AB) 



Siippl. Service(AC, SMPT 
Sjippl. Service(AB, HMPT 



DISCONNECT(AC) 

< ► 



... release of AC 
without release of 



Release(AC) 



RetrieveMPTY(AB) 



=ietrieveMPTY ACK(AB) 



Siippl. Service(AB, RMPT 



DISCONNECT(AB) 

< ► 



... release of AB ca|ll and interception 
as in figure A1 ... 



Release(AB) 



Clll 



and interception ^s in figure A1 
tjhe stublines ... 







REL 



in figure A1 



REL 



Figure A.5: Interception of multiparty calls - stublines per target 
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Figure A.6: Interception of multiparty calls - stublines per target call 
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A.5 Call forwarding / call deflection 

The following pictures show the information flows for the interception of forwarded calls. Information flows will be 
given for three typical cases of call forwarding. All other types of call forwarding / call deflection are intercepted 
similar to one of these. 



A.5.1 Unconditional call forwarding 



Figure A.7 shows the interception of unconditionally forwarded calls. The mobile that activated unconditional call 
forwarding (B) is the target for interception. In this case interception will be performed at the GMSC, where the SRI 
request for B is issued and subsequently the SRI response indicating that the call must be forwarded is received back. 
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Figure A.7: Interception of unconditional call forwarding 



A. 5. 2 Call forwarding on not reachable (IMSI detached) 

Call forwarding on not reachable because the IMSI is detached is also handled on the GMSC. Interception of this type 
of call forwarding is similar to interception of unconditional call forwarding. 
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A. 5. 3 Call forwarding on busy (network determined) 

Figure A.8 shows the interception of call forwarding on busy (network determined). The mobile that activated call 
forwarding on busy (B) is the target for interception. In this case interception will be performed at the MSC/VLR where 
B resides, where the busy condition is detected and the call is forwarded. 
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Figure A.8: Interception of call forwarding on busy (network determined) 

A. 5. 4 Call forwarding on not reachable (no response to 
paging/radio channel failure) 

Call forwarding on not reachable because of no response to paging or radio channel failure is also handled on the 
MSC/VLR similar to call forwarding on busy (network determined). Interception of this type of call forwarding is 
therefore done in the same way. 
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A. 5. 5 Call forwarding on no reply 



Figure A.9 shows the interception of call forwarding on no reply. The mobile that activated call forwarding on no reply 
(B) is the target for interception. In this case interception will be performed at the MSC/VLR where B resides, where 
the no reply condition is detected and the call is forwarded. Initially, the interception is similar to the interception of a 
basic mobile terminated circuit switched speech of data call. On no reply time-out, the interception will continue on the 
forwarded call to C. 
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Figure A.9: Interception of call forwarding on no reply 

In figure A.9 the release of the stublines is done after the forwarded call is released by A or C. It is a national option not 
to support interception of forwarded calls. In that case, the release of the stublines is done after the call is forwarded and 
B is no longer involved. 

A. 5. 6 Call forwarding on busy (user determined)/call deflection 

Call forwarding on busy (user determined) and call deflection are also handled on the MSCA'^LR similar to call 
forwarding on no reply. Interception of this type of call forwarding is therefore done in the same way. 
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A. 5. 7 Call waiting / call forwarding on no reply 

Figures A. 10 and A. 1 1 show the interception of a call involving both call waiting and call forwarding on no reply. 
Figure A. 10 covers the case where one pair of stublines is used per target, figure A.l 1 covers the case where a pair of 
stublines is used for each target call. The mobile that activated call forwarding on no reply and receives the waiting call 
(B) is the target for interception. In figure A. 10 a new (pair of) stublines needs to be set up when the call is forwarded 
since the first (pair of) stublines is still used for the initial call. 
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Figure A.10: Interception of call waiting / call forwarding on no reply - stublines per target 
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Figure A.11 : Interception of call waiting / call forwarding on no reply - stublines per target call 
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A.6 Explicit call transfer 



Figures A. 12 and A. 13 show the interception of explicit call transfer. Figure A. 12 covers the case where one pair of 
stublines is used per target, figure A. 13 covers the case where a pair of stublines is used for each target call. The mobile 
transferring the call (B) is the target for interception. 
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Figure A.12: Interception of explicit call transfer - stublines per target 
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Figure A.13: Interception of explicit call transfer - stublines per target call 

In figures A. 12 and A.13 the release of the stublines is done after the transferred call is released by A or C. It is a 
national option not to support interception of transferred calls. In that case, the release of the stublines is done after the 
call is transferred and B is no longer involved. 
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Annex B (normative): 
Interception for GPRS 

B.1 Architecture 

The following picture contains the reference configuration for the lawful interception for GPRS systems. The various 
entities and interfaces are described in more detail in the succeeding sections. Interception takes place within the SGSN. 
As a national option, the GGSN may be used for interception. 

There is one Administration Function (ADMF) in the network. Together with the delivery functions it is used to hide 
from the SGSN and GGSN that there might be multiple activations by different Law Enforcement Agencies (LEAs) on 
the same target. 
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Figure B.I : Reference configuration for GPRS 

The GSN (GPRS Support Node) can be SGSN or GGSN. The reference configuration is only a logical representation of 
the entities involved in lawful interception and does not mandate separate physical entities. This allows for higher levels 
of integration. 



B.2 Activation, deactivation and interrogation 

The following picture shows the extract from the reference configuration which is relevant for activation, deactivation 
and interrogation of the lawful interception for the GPRS system. 
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Figure B.2: Functional model for GPRS Lawful Interception activation, 
deactivation and interrogation 



£75/ 



3GPP TS 43.033 version 9.0.0 Release 9 42 ETSI TS 1 43 033 V9.0.0 (201 0-02) 

In addition to the typical GPRS functional entities, a new functional entity is introduced - the ADMF - the Lawful 
Interception administration function. The ADMF: 

interfaces with all the LEAs that may require interception in the PLMN; 

keeps the intercept activities of individual LEAs separate; 

- interfaces to the PLMN. 

Every physical SGSN or GGSN is linked by an own Xl_lp-interface to the ADMF. Consequently, every single SGSN 
or GGSN performs interception (activation, deactivation, interrogation as well as invocation) independently from other 
SGSNs or GGSNs. The X0_1 -interface represents the interface between the requester of the lawful interception and the 
Lawful administration function; it is included for completeness, but is beyond the scope of the present document. 

The target identity for GPRS interception can be the IMSI, MSISDN or IMEI. 

NOTE 1: Interception by MSISDN works only with the basic MSISDN. 

In case of location dependent interception the following network/national options exist: 

target location versus Interception Areas (lAs) check in the SGSN and Delivery Functions (DFs); 

target location versus lAs check in the DFs. (physical co-location of the SGSN and DFs may be required by national 
law). 

NOTE 2: The lA is previously defined by a set of cells. From the location of the target this set of cells permits to 
find the relevant I As. 

NOTE 3: The GGSN is not used for interception when location dependent interception is invoked in the network. 

B.2.1 Activation 

The following pictures show the information flow for the activation of the Lawful interception. 

B.2.1.1 X1_1p-interface 

The message sent from the ADMF to the GSN through the Xl_lp interface contains the following: 

identity of the target ; 

information whether the IP shall be provided (see note 1); 

information whether the IRI shall be provided (see note 1); 

address of Delivery Function 2 (DF2P) for the IRI (see note 2); 

address of Delivery Function 3 (DF3P) for GPRS product (see note 3); 

lA in case of location dependent interception. 

NOTE 1 : As an option, the filtering whether intercept product and/or intercept related information has to be 

provided can be part of the delivery functions. If the option is used, the corresponding information can be 
omitted on the Xl_lp-interface, while "information not present" means "intercept product and related 
information has to be provided" for the GSN. Furthermore the delivery function which is not requested 
has to be "pseudo-activated", in order to prevent error cases at invocation. 

NOTE 2: As an option, only a single DF2P is used by and known to every SGSN or GGSN in the network. In this 
case the address of DF2P can be omitted. 

NOTE 3: As an option, only a single DF3P is used by and known to every SGSN or GGSN in the network. In this 
case the address of DF3P can be omitted. 

If after activation subsequently IP (Intercepted product) or IRI has to be activated an "activation change request" with 
the same target ID is to be sent. 
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Figure B.3: Information flow on Xllp-interface for Lawful Interception activation 

Interception of a target can be activated on request from different LEAs and each LEA may request interception via a 
different identity. In this case, each identity of the target on which to intercept will need to be sent via separate 
activation message from ADMF to GSN on the Xl_lp-interface. Each activation can be for IP only, IRI only, or both IP 
and IRI. 

When several LEAs request activation on the same identity then the ADMF determines that there are existing 
activations on the identity. In this case, the ADMF will not send an additional activation message to the GSN except 
when the activation needs to change from IP only or IRI only to IP and IRI. In that case an activation change message 
will be sent to the GSN. 

B.2.1.2 X1_2p-interface (IRI) 

For the delivery of IRI the message sent from the ADMF to the Delivery Function contains: 

the identity of the target; 

the address for delivery of IRI (= LEA address); 

which subset of information shall be delivered; 

a DF2P activation identity, which uniquely identifies the activation for DF2P and is used for further interrogation 
or deactivation, respectively; 

the warrant reference number if required by national option; 

lA in case of location dependent interception. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single activation of delivery is 
necessary for each combination of LEA and identity. 
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Figure B.4: Information flow on X1_2p-interface for Lawful Interception activation 

B.2.1.3 X1_3p-interface (IP) 

For the delivery of GPRS intercept product the message sent from the ADMF to the DeUvery Function contains: 

the identity of the target; 

the address of deUvery for IP (= LEA address); 

a DF3 activation identity, which uniquely identifies the activation for delivery function 3 and is used for further 
interrogation or deactivation, respectively; 

the warrant reference number if required by national option; 

lA in case of location dependent interception. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single activation of delivery is 
necessary for each combination of LEA and identity. 
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Figure B.5: Information flow on X1_3p-interface for Lawful Interception activation 
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B.2.2 Deactivation 

The following picture shows the information flow for the deactivation of the Lawful interception. 

B. 2.2.1 X1_1p-interface 

The messages sent from the ADMF to the GSN for deactivation contains; 
the identity of the target; 
lA in case of location dependent interception. 
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Figure B.6: Information flow on X1_1p-interface for Lawful Interception deactivation 

If interception of a target has been activated via different identities then a separate deactivation message will need to be 
sent from the ADMF to the GSN for each identity. 

When several LEAs requested activation on the same identity and subsequently request deactivation then the ADMF 
determines that there are remaining activations on the identity. In this case, the ADMF will not send a deactivation 
message to the GSN except when the activation needs to change from IP and IRI to IP only or IRI only. In that case an 
activation change message will be sent to the GSN. 
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B.2.2.2 X1_2p-interface (IRI) 



The ADMF sent for the deactivation to the Delivery Function 2 of the Intercept Related Information: 

a DF2P activation id, which uniquely identifies the activation to be deactivated for DF2P. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single deactivation is necessary for 
each combination of LEA and identity. 
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Figure B.7: Information flow on the X1_2p-interface for Lawful Interception deactivation 

B.2.2.3 X1_3p-interface (IP) 

For the deactivating the delivery of the IP the message from the ADMF to the Delivery Function contains: 

a DF3P activation id, which uniquely identifies the activation to be deactivated for DF3P. 

If a target is intercepted by several LEAs and/or several identities simultaneously, a single deactivation is necessary for 
each combination of LEA and identity. 
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Figure B.8: Information flow X1_3p-interface for Lawful Interception deactivation 
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B.2.3 Interrogation 



The purpose of interrogation is consistency checking for the interception function. It can be use e.g. for audit 
functionality, but this is beyond the scope of the present document. 

Interrogation of all activations for a given LEA is an ADMF filter function. 

B. 2.3.1 Interrogation of the SGSN and GGSN 

The following picture shows the information flow for the interrogation of the Lawful interception. It must be possible to 
interrogate 

a specific activation at this GSN for a given target identity; 

all activations at this GSN. 

As result of the interrogation the activation status and data are returned. 



ADMF 



request for lawful 
interception interrogation 



response for lawful 
interrogation 



lawful interception 
interrogation 



lawful interception 
interrogation ack 



... interrogation on 
X1_2p and X1_3p ... 



GSN 



Figure B.9: Interrogation of the Lawful Interception (GSN) 



B.2.3. 2 Interrogation of Delivery Functions 



The following picture shows the information flow for the interrogation of the Lawful interception. It must be possible to 
interrogate: 

a specific activation at a Delivery Function for a given activation id; 

all activations at a Delivery Function for a given target identity; 

all activations at a Delivery Function. 

As result of the interrogation the activation status and data are returned. 
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Figure B.10: Interrogation of the Lawful Interception (Delivery Functions) 



B.3 Invocation of Lawful Interception 

The following picture shows the extract from the reference configuration which is relevant for the invocation of the 
lawful interception. 
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Figure B.11: Functional model for GPRS Lawful Interception invocation 

The X0_2 and X0_3-interfaces represent the interfaces between the LEA and two delivery functions. Both interfaces are 
subject to national requirements. They are included for completeness, but are beyond the scope of the present document 
. The delivery functions are used: 

to convert the information on the X2p-interface to the corresponding information on the X0_2-interface; 

to distribute the intercept related information to the relevant LEA(s); 

to distribute the intercept product to the relevant LEA(s). 

In case a packet data communication is selected based on several identities (MSISDN, IMSI, IMEI, ,) of the same 
target, the SGSN or GGSN will deliver IP and IRI only once to the DF2P and DF3P. DF2P and DF3P will then 
distribute the information to the relevant LEA that requested interception on a particular target identity. 

For the delivery of the IP and IRI the SGSN or GGSN provides correlation number and target identity to the DF2P and 
DF3P which is used there in order to select the different LEAs where the product shall be delivered to. 

The correlation number is unique in the whole PLMN and is used to correlate IP with IRI and the different IRI's of one 
PDP context. 

The correlation number shall be generated by using existing parameters related to the PDP context. 

NOTE: If interception has been activated for both parties of the packet data communication both IP and IRI will 
be delivered for each party as separate intercept activity. 

In case of location dependent interception : 
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for each target, the location dependency check occurs at each packet data session establishment or release and at 
each cell and/or RA update to determine permanently the relevant lAs (and deduce, the possible LEAs within 
these lAs), 

concerning the IRI: 

when an lA is left, a GPRS detach event is sent when changing SGSNs or a cell and/or RA update event is 
sent when changing lAs inside the same SGSN to DF2P. 

when a new lA is entered a cell and/or RA update event is sent to DF2P and, optionally, a Start of 
Interception with Active PDP Context event for each PDP context 

concerning the IP, when crossing lAs, the IP is not sent anymore to the DF3P of the old lA but sent to the 
DF3PofthenewIA. 

B.3.1 Provision of Intercept Product - GPRS 

The access method for the delivering of GPRS Intercept Product is based on duplication of packets without 
modification at GSN The duplicated packets with additional information in the header are sent to DF3P for further 
delivery via a tunnel. 
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Figure B.12: Configuration for interception of GPRS product data 

B.3.1.1 X3p-interface 

The following information needs to be transferred from the GSN to the DF3P in order to allow the DF3P to perform its 
functionality: 

the identity of the target; 

correlation number; 

the target location (if available) or the lAs in case of location dependent interception. 

Additional information may be provided as a national option. 
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B.3.2 Provision of Intercept Product - Short IVIessage Service 

Figure B13 shows an SMS transfer from the SGSN to the LEA. Quasi-parallel to the delivery from / to the mobile 
subscriber a message, which contains the contents of the SMS, is generated and sent via the Delivery Function 2P to the 
LEA in the same way as the Intercept Related Information. 

The IRI will be delivered to the LEA: 

- for a SMS-MO, when the SMS-Centre receives the SMS; 

- for a SMS-MT, when the MS receives the SMS. 
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Figure B.13: Provision of Intercept Product - Short Message Service 

B.3.3 Provision of Intercept Related Information 

Intercept Related Information (Events) are necessary at the GPRS Attach, GPRS Detach, PDP Context Activation, Start 
of intercept with PDP context active, PDP Context Deactivation, Cell and/or RA update, and SMS events. 

Figure B 14 shows the transfer of intercept related information to the DF2P. If an event for / from a mobile subscriber 
occurs, the GSN sends the relevant data to the DF2P. 
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Figure B.I 4: Provision of Intercept Related Information 
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B. 3.3.1 X2p-interface 



The following information needs to be transferred from the GSN to the DF2P in order to allow a DF2P to perform its 
functionality: 

- identity of the target (MSISDN, IMSI, IMEI); 

events and associated parameters as defined in section B.3.3.2 and B.3.3.3 may be provided; 
the target location (if available) or the lAs in case of location dependent interception. 

B.3.3.2 Structure of the events 

There are seven different events in which the information is sent to the DF2P if this is required. Details are described in 
following section. The events for interception are configurable (if they are sent to DF2P) in the SGSN or GGSN and can 
be suppressed in the DF2P. 

The following events are applicable to SGSN: 

- GPRS attach; 

- GPRS detach; 

PDP context activation; 

Start of intercept with PDP context active; 

PDP context deactivation; 

Cell and /or RA update; 

- SMS. 

NOTE: GGSN interception is a national option 
The following events are applicable to GGSN: 
PDP context activation ; 
PDP context deactivation ; 
Start of interception with PDP context active. 
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A set of fields as shown below is used to generate the events. The events transmit the information from GSN to DF2P. 
This set of fields as shown below can be extended in the GSN, if this is necessary as a national option. DF2P can extend 
this information if this is necessary as a national option e.g. a unique number for each surveillance warrant. 



observed MSISDN 

MSISDN of the target subscriber (monitored subscriber) 



observed IIVISI 

IIVISI of tlie target subscriber (monitored subscriber) 



observed IIVIEI 

IIVIEI of tlie target subscriber (monitored subscriber) Jt must be checl<ed for eacli activation over the radio interface. 



event type 

Description which type of event is delivered: PDP attach, PDP detach, PDP context activation. Start of intercept with 

PDP context active, PDP context deactivation, SIVIS, Cell and/or RA update, 



event date 

Date of the event generation in the GSN 



event time 

Time of the event generation in the GSN 



PDP address 

The PDP address of the target subscriber. Note that this address might be dynamic. 



Access Point Name 

The APN of the access point. 



Routing Area Code 

The routing area code of the target defines the RA in a PLIVIN. 



PDP Type 

The used PDP type. 



Correlation Number 

The correlation number is used to correlate IP and IRI. 



SMS 

The SIVIS content with header which is sent with the SMS-service. The header also includes the SMS-Centre 

address. 



CGI 

Cell Global Identity 



Failed attach reason 

Reason for failed attach of the target subscriber. 



Failed context activation reason 

Reason for failed context activation of the target subscriber. 



lAs 

The observed Interception Areas 



B. 3.3.3 GPRS related events 



B.3.3.3.1 



GPRS attach 



For attach an attach-event is generated. When an attach activation is generated from the mobile to SGSN this event is 
generated. These fields will be delivered to the DF2P if available: 



Observed MSISDN 



Observed IMS! 



Observed IMEI 



Event Type 



Event Time 



Event Date 



CGI 



Routing area code 



Failed attach reason 



lAs (if applicable) 
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B.3.3.3.2 GPRS detach 

For detach a detach-event is generated, this is for the common (end) detach. These fields will be delivered to the DF2P 
if available: 



Observed MSISDN 



Observed IMSI 



Observed IMEI 



Event Type 



Event Time 



Event Date 



CGI 



Routing Area code 



lAs (if applicable) 



B.3.3.3.3 GPRS PDP context activation 

For PDP context activation a PDP context activation-event is generated. When a PDP context activation is generated 
from the mobile to GSN this event is generated. These fields will be delivered to the DF2P if available: 



Observed MSISDN 



Observed IMSI 



Observed IMEI 



PDP address of observed party 



Event Type 



Event Time 



Event Date 



Correlation number 



Access Point Name 



PDP Type 



CGI 



Routing area code 



Failed context activation reason 



lAs (if applicable) 



B.3.3.3.4 Start of interception with PDP context active 

This event will be generated if interception for a target is started and if the target has at least one PDP context active. If 
more then one PDP context are open for each of them an event record is generated. These fields will be delivered to the 
DF2P if available: 



Observed MSISDN 



Observed IMSI 



Observed IMEI 



PDP address of observed party 



Event Type 



Event Time 



Event Date 



Correlation number 



Access Point Name 



PDP Type 



CGI 



Routing area code 



lAs (if applicable) 
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B.3.3.3.5 GPRS PDP context deactivation 

At PDP context deactivation a PDP context deactivation-event is generated. These fields will be delivered to the DF2P 
if available: 



Observed MSISDN 



Observed IMSI 



Observed IMEI 



PDP address of observed party 



Event Type 



Event Time 



Event Date 



Correlation number 



Access point name 



CGI 



Routing area code 



lAs (if applicable) 



B.3.3.3.6 Cell and/or RA update 

For each cell and/or RA update an update-event with the fields about the new location is generated. These fields will be 
delivered to the DF2P if available: 



Observed IVISISDN 



Observed IMSI 



Observed IMEI 



Event Type 



Event Time 



Event Date 



CGI 



Routing area code 



lAs (if applicable) 



B.3.3.3.7 



SMS 



For MO-SMS the event is generated in the SGSN, when the SMS-Centre successfully receives the SMS; for MT-SMS 
the event is generated in the SGSN when the target receives the message. This fields will be delivered to the DF2P if 
available: 



Observed MSISDN 



Observed IMSI 



Observed IMEI 



Event Type 



Event Time 



Event Date 



CGI 



Routing area code 



SMS 



lAs (if applicable) 



B.3.4 Intercept cases for supplementary services 

Supplementary services may be used with GPRS. However they are not standardised and therefore Lawful Interception 
interwork cases can not be defined. 
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B.4 Security 
B.4.1 Security 

The security requirements are valid for the whole Lawful Interception system, i.e. rules and procedures shall be used for 
all involved entities, GSN and the DF. 

B.4. 1.1 Administration security 

The administration of the LI function, i.e. Activation, Deactivation and Interrogation of Lawful Interception, in the GSN 
and the DFs must be done secure as described below: 

It shall be possible to configure the authorised user access to Activation, Deactivation and Interrogation of 
Lawful Interception separately for every physical or logical port at the GSN and DF. This configuration 
possibility shall be password protected. 

Normally only the ADMF is allowed to have access to the LI functionality in the GSN and DF. 

The communication link between ADMF, GSN, DF2P, and DF3P shall be secure and shall support security 
mechanisms, e.g.: 

- CUG / VPN; 

- COLP; 

authentication; 
encryption. 
No network entities or remote equipment shall be able to access or manipulate LI data in the GSN or the DF. 

B.4. 1.2 IRI security 

B.4. 1.2.1 Normal operation 

The transmission of the IRI shall be done in a secure manner. 

When DF2P is physically separate from the GSN, the X2p-interface shall support security mechanisms, e.g.: 

- CUG/VPN; 

- COLP; 

- authentication; 

- encryption. 

B.4. 1.2. 2 Communication failure 

Depending on the national law in case of communication failure IRI may be buffered in the GSN. After successful 
transmission of IRI the whole buffer must be deleted. It shall be possible to delete the content buffer via command or a 
timer, in an unrestoreable fashion. 
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B.4.1.3 IP security 

The transmission of the IP shall be done in a secure manner. 

When DF3P is physically separate from the GSN, the X3p-interface shall support security mechanisms, e.g.: 

- CUG/VPN; 

- COLP; 

- authentication; 

- encryption. 

In case of transmission failure no buffering will be done. 

B.4.1 .4 Security aspects of Lawful Interception billing 

Billing information shall be available at the DFs and the ADMF. Billing information for Lawful Interception shall be 
separated from "regular" GPRS billing data. 

Billing data transmission to the Lawful Interception billing system shall be done in a secure manner. 

In case of transmission failure billing-data shall be buffered/stored in a secure way. After successful transmission billing 
data shall be deleted in an unrestorable fashion. 

B.4. 1 .5 Other security issues 
B.4.1. 5.1 Log files 

Log files shall be generated by the ADMF, DF2P, DF3P and the GSN. All log files are retrievable by the ADMF, and 
are maintained by the ADMF in a secure manner. 

B.4.1. 5. 2 Data consistency 

The administration function in the PLMN shall be capable to perform a periodic consistency check to ensure whether 
the target list of MSISDN, IMSI or IMEI is the same in all involved SGSNs in the PLMN and the DFs. The reference 
data base is the ADMF data base. 
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B.5 Information flows for Lawful Interception invocation 
(informative) 

The following figures show the information flows for the invocation of Lawful Interception for GPRS and typical 
scenarios. The figures show some of the basic signalling messages of the target packet data communication and the 
events on the X2P and X3P-interfaces. The dotted lines indicate signalling depending on whether IP and/or IRI 
information has been requested. GGSN may setup/release packet tunnels and send IRI information depending on 
national requirements. 

The use of the GGSN for interception is a national option. 

B.5.1 GPRS attach 

Figure B.15 shows the interception of a basic GPRS attach where the mobile (A) is the target for interception. 
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Figure B.15: Interception of mobile originated GPRS attachment 



B.5.2 Mobile originated GPRS detach 



Figure B.16 shows the interception of a mobile originated GPRS detach where the originating mobile (A) is the target 
for interception. 
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Figure B.16: Interception of mobile originated GPRS detachment 
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B.5.3 Network initiated GPRS detach 

Figure B.17 shows the interception of a network initiated (by SGSN or HLR) GPRS detach where the mobile (A) is the 
target for interception. 
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Figure B.17: Interception of network initiated GPRS detach 

NOTE: * Additional signals in case of HLR initiated 

B.5.4 Intra SGSN Routing Area Update 

Figure B.18 shows the interception of an Intra Routing Area Update where the mobile (A) is the target for interception. 
The sequence is the same for the combined RA / LA Update procedure but additional signalling is performed between 
the SGSN and MSC/VLR, HLR and the old MSCA^LR before the Routing Area Update Accept message is sent to the 
MS. 
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Figure B.18: Interception of an Intra Routing Area Update 
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B.5.5 Inter SGSN Routing Area Update 

Figure B. 19 shows the interception of an Inter Routing Area Update where the mobile (A) is the target for interception. 
The sequence is the same for the combined RA / LA Update procedure but additional signalling is performed between 
the SGSN and MSC/VLR, HLR and the old MSC/VLR before the Routing Area Update Accept message is sent to the 
MS. In case of PDP context not being active less signalling is required. 
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Figure B.19: Interception of an Inter Routing Area Update 
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B.5.6 PDP Context Activation 

Figure B.20 shows the interception of a PDP Context activation where the mobile (A) is the target for interception. The 
sequence for a network initiated PDP Context activation is analogous but is preceded by the SGSN sending a Request 
PDP Context Activation to the MS. 



DF2P 



DF3P 



MS A SGSN GGSN 

Activate PDP Co i text Re<|iiest 



PDP 



Security function ; 



Setup of GPRS |>iicket tuiiiiel 



Context Activiition 



Create PDP Contt xt Request 



Create PDP Contt xt Response 



Setup of GFRS packet tunnel 
PDP Context Actiya^ 
Activate PDP Coi text Accept 



Figure B.20: Interception of a PDP Context Activation 



B.5.7 Start of interception with PDP context active 

A tunnel is established to DF3P and an event is sent to DF2P. 
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B.5.8 MS initiated PDP Context Deactivation 

Figure B.21 shows the interception of a MS initiated PDP Context deactivation where the mobile (A) is the target for 
interception. 
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Figure B.21 : Interception of a PDP Context Deactivation 



B.5.9 Network initiated PDP Context Deactivation 

Figure B.22 shows the interception of a Network initiated PDP Context deactivation where the mobile (A) is the target 
for interception. The GGSN may send, (depending on national requirements) the PDP Context deactivation and release 
the GPRS packet tunnel after the Delete PDP Context Response has been sent or received, (signalling between the 
SGSN and the GGSN is not shown here). 



DF2P 



DF3P 



MSA 



GSN 



Deactivate PD 



context Request 



Deactivate PDP Context Accept 



Release of GPRS packet tunnel 
PDP ContextDeactivation 



Figure B.22: Interception of a Network initiated PDP Context Deactivation 
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B.5.10 SMS 

Figure B.23 and B.24 shows the interception of a Mobile-terminated SMS and a Mobile-originated SMS transfer where 
the mobile (A) is the target for interception. 
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Figure B.23: Interception of a Mobile-terminated SMS transfer 
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Figure B.24: Interception of a Mobile-originated SMS transfer 
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